1. Field of the Invention
The present invention relates generally to mobile communication methods and systems. More particularly, but not exclusively, the present invention relates to transmitting information relating to the network's capabilities to transmit voice information via a packet switched network portion, to voice call continuity services and/or transmitting information relating to the terminal's capability to support.
2. Description of the Related Art
Outline Description of VCC and its Associated Call Origination Procedures
A 3rd Generation Partnership Project (3GPP) Voice Call Continuity (VCC) service provides the capability to transfer the path of a voice call between a Circuit-Switched (CS) domain and an Internet Protocol (IP) Multimedia Subsystem (IMS) domain, and vice versa. The service assumes a User Equipment (UE) capable of supporting two separate call legs related to the same voice communication (one over the CS domain and one over the IMS domain). In order to facilitate the transfer of calls between the domains, all CS & IMS voice calls from and to VCC capable UEs are anchored in the subscriber's IMS domain.
FIG. 1 illustrates functional architecture for a VCC. FIG. 1 is similar to the existing 3GPP reference architecture in that a Call Continuity Control Function (CCCF) is implemented as a Session Initiation Protocol (SIP) Application Server (AS). At the time of writing, it has not been agreed whether CCCF and a Network Domain Selection function (NeDS) should be co-located. However, FIG. 1 assumes that the CCCF and the NeDS are co-located, hence only one IMS Service Control (ISC) interface is illustrated.
A UE registers with a CCCF at a time of UE IMS registration, following the procedure defined in 3GPP TS 23.288 for Application Server registration with the filter criteria set that 3rd party registration is required via IMS Service Control (ISC) interface.
A CCCF exists for each voice continuity event in the system and controls the establishment of call legs required to transfer a call between the CS and the IMS domains. If a UE is involved in multiple calls all requiring VCC, then a separate CCCF exists for each call.
VCC Registration
During and following the IMS registration procedure, VCC information is exchanged between a UE and a CCCF. This includes:                From UE=>CCCF                    UE CS status (detached, attached-idle/attached-active)            User preferences                        From CCCF=>UE                    CCCF PSI and associated CS routing number            Operator policy                        
The exact information exchange mechanism has not yet been specified, but the post registration exchange of information is likely to be handled by a mutual SIP Subscribe/Notify process, i.e. the UE subscribes to information from the CCCF, and the CCCF subscribes to information from the UE. Each will in turn be notified upon initial subscription and as information changes.
Call Origination from IMS Domain
At the time of call origination from the IMS domain, the SIP INVITE is routed via the Call Session Control Function (CSCF) to the CCCF using initial filter criteria. The CCCF records the call event, e.g., assigns a call reference and records route to stay in signalling path for call, and routes the call back to the Serving CSCF (S-CSCF) so that S-CSCF can perform termination handling to IMS/CS domains as defined in 3GPP TS 23.228. IMS anchoring of VCC calls originated in the IMS domain is independent of whether the UE is CS attached or detached.
If the terminal is not capable of supporting VCC procedures, but the user is a subscriber to VCC services, the lack of VCC capability in the terminal could be informed to the CCCF during IMS registration. In that case, the CCCF could decide not to IMS anchor the call. Given that S-CSCF and CCCF are both located in the user's home network, and that the IMS bearer is established end-to-end, it is debatable whether there would be much benefit in not IMS anchoring an IMS originated call from a VCC subscriber.
Call Origination from CS Domain
The default mechanism (only mandated mechanism) for IMS anchoring of VCC calls originated in the CS domain is to use Customized Applications for Mobile network Enhanced Logic (CAMEL) triggers at the Visited Mobile Switched Center (VMSC). This means it is possible to anchor calls even if the UE is not IMS registered at the time of call originating.
If the terminal is not capable of supporting VCC procedures, but the user is a subscriber to VCC services, the CCCF for the call cannot be aware of the lack of VCC capability in the terminal, as no prior exchange of VCC information will have been possible between the UE and CCCF.
FIG. 2 illustrates a message flow for CS originated VCC calls.                1. A Call Control SETUP message is sent from the UE to the VMSC.        2. Originating CAMEL Subscription Information (O-CSI) triggering in gsm Service Switching Function (SSF) at VMSC sends InitialDP message towards gsmSCF function of CCCF.        3. CCCF creates an Internet Protocol (IP) Multimedia Routing Number (IMRN) which gsmSCF returns to VMSC in CONNECT message (CCCF notes information required to complete call towards called party).        4. VMSC routes call towards MGCF in user's home IMS network using IMRN.        5. MGCF initiates SIP INVITE towards Interrogating CSCF (I-CSCF).        6. I-CSCF retrieves from a Home Subscriber Server (HSS) the CCCF associated with IMRN and forward the SIP INVITE.        7. The CCCF terminates incoming leg and initiates outgoing leg towards original called party acting as Back-to-Back User Agent (B2BUA).        